Various secure applications provide restrictions on user access and user access protocols for a number of reasons. User access is restricted in order to protect sensitive data, value in an account, etcetera. User access protocols are adopted to ensure compliance with governmental regulations or requirements, business goals, etcetera. As user needs change, regulations or requirements are revised, and business goals change it may be burdensome to alter the secure interface of many secure applications.
As but one example of a secure application, postage printing applications provide user control and access to postage value for generating and printing postage indicia. Online postage generation and printing is provided through the use of secure postal servers having crypto vaults for storing postage credit. Postal clients, uniquely configured to implement the security protocols of the secure postal servers, allow a user to remotely access a postal server and perform functions with respect to an associated account, such as query a balance, add postage value, and deduct postage value and generate a postage indicia.
User access to such secure postal servers has been tightly controlled, such as by postal service rules and regulations establishing the types of user credentials that are to be used, the number of user credentials allowed to be active with respect to an account, etcetera. For example, current configurations of secure postal servers, in accordance with postal regulations, provides a single customer identifier (e.g., a business in the case of a commercial account or an individual in the case of a private user account) in association to a postal account. However, for various reasons (e.g., internal accounting reasons), a customer may desire to provide multiple uniquely identified users access to the postal account. At present, the solution has been to allow users of the postal account to input reference information (e.g., notes for identifying a business department, project, user, etcetera) in association with certain operations (e.g., printing postage). Such reference information may easily be erroneously input or even maliciously misinput, thus often resulting in it being of little value.
Many such secure applications have substantial amounts of code dedicated to implementing particular security protocols and user access restrictions known to meet applicable rules, regulations, and objectives and which are acceptable to the appropriate entities (e.g., governmental agencies, business partners, etcetera). As new security protocols are determined to be acceptable, as new user access scenarios are identified, and/or new technologies are developed it can be difficult and costly to implement changes in the secure applications to facilitate use of these developments.
For example, as postage printing applications providing remote user access over a public network, such as the Internet, were being developed, a lack of history with respect to security protocols may have suggested that clients should be utilized by users which employ security protocols unique to the secure postal servers. Such clients require that a user obtains client software, such as by disk or download, in order to be able to access the corresponding secure server, thus making their use somewhat inconvenient for users, at least initially. Clients employing proprietary security protocols (referred to hereinafter as proprietary clients) are also more difficult to integrate into other products, such as software providing symbiotic functions, and thus presents a barrier to adoption and integration by third party vendors. Moreover, various embodiments of such security protocols may have implemented features which made them unique to the particular terminal using the security protocol, requiring re-registration when the same user (or user accessing the same account) attempts to access the secure postal server from a different user terminal.
As security technology improves and as historical information is developed with respect to remote user access to such secure applications, it may be determined that one or more of the secure access protocol features is not necessary. However, the secure access protocol may be deeply embedded in the secure application and/or tightly coupled to the operation of various features thereof, requiring substantial time and effort to implement even seemingly simple changes. Moreover, because it is generally the secure application itself which is to be altered in such situations, any changes to the secure access protocol may require testing and approval by particular entities prior to its implementation, such as to confirm that overall security with respect to accounts etcetera has not been compromised.